home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 5 / Apprentice-Release5.iso / Source Code / C / Applications / Python 1.3.3 / Python 133 SRC / Mac / mwerks / malloc / README < prev   
Encoding:
Text File  |  1995-08-31  |  3.1 KB  |  81 lines  |  [TEXT/R*ch]
  1.  
  2.         What is this?
  3.         -------------
  4. This package is a memory allocator for the Macintosh. It was initially
  5. implemented for use with the MetroWerks CodeWarrior compiler on the
  6. PowerPC Mac, but may also be useful (in a more limited way) for use
  7. with MW 68K or Think compilers.
  8.  
  9. This is distribution 1.0, dated April 19, 1995.
  10.  
  11.         How does it work?
  12.         -----------------
  13. Actually, 99% of the code comes straight from the old old BSD-unix
  14. "fast malloc", only the interface to the low-level memory allocator
  15. and the handling of large blocks is different. The allocator follows
  16. one of two strategies, based upon block size:
  17. - for small blocks (anything up to 8K, as distributed), the size is
  18.   rounded up to the next power of two, and that much is
  19.   allocated. Realloc, etc. understand about this. Small blocks are
  20.   packed into 8K segments.
  21. - Larger blocks are allocated directly using NewPtr().
  22.  
  23.         Why should I want it?
  24.         ---------------------
  25. The reason for writing this is that I've had serious problems with MW
  26. malloc, especially in one piece of software, the Python
  27. interpreter. Python is a very-high level interpreted language, and
  28. spends very large amounts of time in malloc. Moreover, it reallocs()
  29. like there's no tomorrow, and allocates and frees tiny and huge blocks
  30. intermixedly. After some time running, this caused two things (using
  31. the original MW malloc): memory useage grew exponentially and so did
  32. runtime. MetroWerks have tried to be helpful, but I have been unable
  33. to provide them with simple sample-programs that showed the problem:
  34. it seems to be something to do with fragmentation and only happens
  35. under very heavy use.
  36.  
  37. The 68K MW malloc has the same problems, and the Think C malloc
  38. has a similar one: it shows the same growth problem but not the
  39. increase in runtime.
  40.  
  41. Two additional reasons for using it:
  42. - It is blindingly fast.
  43. - It has pretty good range checking and such (enabled with a #define),
  44.   so it'll help you catch various programming errors like referencing
  45.   outside the bounds of the malloced block.
  46.  
  47. One reason for not using it:
  48. - It is rather wasteful of memory. Small blocks, on average, occupy
  49.   25% more memory than they need, and the allocation in 8K chunks
  50.   wastes another 50K (on average). Also, memory is never returned from
  51.   malloc()s pool to the Memory Manager.
  52.   
  53.         How do I use it?
  54.         ----------------
  55. For MW PPC: simply add the sources to your project. Due to the way the
  56. linker works all mallocs will use the new malloc, even the malloc
  57. calls that come from the libraries (if I'm informaed correctly).
  58.  
  59. For MW 68K: ditto, only supposedly the library malloc calls will still
  60. use the original malloc. The two packages don't bite each other,
  61. however, so there shouldn't be any problems.
  62.  
  63. For Think: more work, but you can rebuild the ANSI library with this
  64. malloc, since the Think distribution contains everything you need for
  65. this.
  66.  
  67.         Is that all?
  68.         ------------
  69.  
  70. Yes. Let me finish off by asking that you send bug reports, fixes,
  71. enhancement, etc to me at the address below.
  72.  
  73.                 Jack Jansen
  74.                 Centrum voor Wiskunde en Informatica
  75.                 Kruislaan 413
  76.                 1098 SJ  Amsterdam
  77.                 the Netherlands
  78.  
  79.                 <Jack.Jansen@cwi.nl>
  80.                 
  81.